Method for acquiring and processing data of business transactions

ABSTRACT

Data concerning business transactions are recorded in a computer system. The data concerning a business transaction specify its type, its time and values of the business transaction which are associated with this time and indicate changes. Predetermined accounts in which the values of the business transaction should effect a corresponding change of account values are associated with each business transaction. At least one ledger structure is provided which has a store structure for ordered storage of book data sets, each book data set being associated with a business transaction. A record identifier which unambiguously identifies the ledger structure and the book data set in the ledger structure is associated with each book data set, and each book data set has an account identifier. The account identifier identifies at least two selected accounts which are a function of the type of business transaction, one of these accounts being a book account with which the ledger structure is associated and the further accounts being cross-accounts associated with the book account. An account object which has an identifier data structure and a store structure for ordered storage of partial entry data sets is formed for each account. Each partial entry data set contains the record identifier of a book data set associated with it as well as at least one value of a business transaction which should effect a corresponding change of account values. In the recording of the data concerning a business transaction the following steps are carried out: First of all a ledger structure, an account object of a book account with which the selected ledger structure is associated, and at least one account object of a cross-account are selected as a function of the type of business transaction and the data concerning the business transaction are read in. Then the book data set and at lest two partial entry data sets are generated from the read-in data, and the book data set is stored in order in the selected ledger structure. Then the at least two partial entry data sets are sent to the appertaining account objects of the book account and of the cross-accounts, whereby the partial entry data sets should contain the values of the business transaction which should effect corresponding changes of account values. Finally the partial entry data sets are received in the account objects and are stored in order in the appertaining store structures. This method of recording and processing data concerning a business transaction creates the prerequisite for a faster creation of up-to-date business management analyses. It utilises the increased processing powers of modem computer systems by allowing an increase in the message traffic between account objects in order to facilitate contemporaneous updating and thus a high speed in the creation and output of analyses.

[0001] The invention relates to a method of acquiring/recording andprocessing data concerning business transactions in a computer system.

[0002] Computer-assisted methods of recording (i.e. acquiring) andprocessing data concerning business transactions constitute the basis ofmodem-day electronic bookkeeping. Before the introduction of mechanisedbookkeeping, bookkeeping was based (hence its name) on bound books witha special division of the pages into columns and lines in which thebusiness transactions were entered manually in an ordered form, i.e. intheir chronological sequence. The ledger formed the principal instrumentof bookkeeping. In this ledger details were entered line by line eachrelating to a business transaction. As a rule the entry included thetime of the business transaction, a description of it and numericalvalues which related primarily to incomings and outgoings of cash valuesin a specific currency and in addition related optionally to specificquantities. The cash values were entered in predetermined columns whichrelated either to persons (columns for customers and suppliers) or notto persons (columns for goods). Moreover, separate columns were keptrespectively for incomings and outgoings, i.e. for debit (positivevalues) and credit (negative values). The values entered on the pages ofthe ledger were added up column by column. The said debit and creditcolumns merely served to simplify the adding up. The businesstransactions were entered in such a way that the “cross“-sum of allcolumn totals of the columns concerning cash values must equal zero.

[0003] Apart from the chronological recording in the ledger, the recordsof the business transactions were entered separately according to thetype of business transaction (for example supply invoicing to acustomer, receipt of invoice from a supplier, incomings and outgoings ona bank account) and optionally separately according to persons(suppliers and customers) in further subsidiary books. At the end of aperiod of time, for example a business day, it was checked whether thetotals of the subsidiary books tallied with those of the ledger.

[0004] With manual bookkeeping there was a later changeover to copybookkeeping (looseleaf bookkeeping) based on loose accounts sheets. Thissystem consisted of a ledger and of various types of accounts sheets. Inaddition to columns for entry date, entry number and text, the ledgercontained three double columns for debit and credit, and in the fieldsadjoining the text column these double columns were arranged to theleft, the middle or the right. The various types of account basicallytook over this division of the lines and columns, but depending upon thetype of account the left, middle or right double column was used.Entries in the various accounts (for example property accounts, debtorand creditor accounts) were copied as they were entered onto the ledge(by means of carbon paper). In this case attention had to be paid to thecorrect arrangement of the superimposed sheets and to entry in thecorrect columns. This was assisted by specific divisions of the sheetsand coloured identifications. In order to reduce the work involved inpicking out and putting back account cards in file card boxes, theledger was expanded by additional columns, the journal. Similarcross-entries were made in the individual columns. The respective totalwas recorded, as a rule after further processing, as a collective entry.For specific accounts in subsidiary bookkeeping systems (for examplewages and salaries accounts, equipment accounts and materials accounts)similar copy bookkeeping arrangements were kept separately.

[0005] Based on the described basic principles and basic structures ofmanual bookkeeping, in the course of technical developments automaticaccounting machines were then developed. The first mechanical versionsof automatic accounting machines or devices for recording businesstransactions were based on a mechanical typewriter which was adapted tothe requirements of copy bookkeeping. Entry in the correct positions andthe correct co-ordination of the copy sheets were assisted bycorresponding guides and mechanical counting means. As electronicsarrived in this field, automatic accounting devices were provided withread-write heads and the accounts sheets were provided with magneticstrips.

[0006] Later digital computers were used for electronic accounting, inwhich accounting programs were run on the computer's processing unit(central unit, CPU) which controlled the electronic recording of dataconcerning business translations, the processing and storage of thesedata and the display and printout of these data. In this case theconfiguration of these data processing systems including their programsand data always corresponded to the organisation as already prescribedby the manual bookkeeping. The business transactions were stored in datasets. Tables which stored the data sets in chronological order (sortedand/or indexed) corresponded to the ledgers. These basic features are tobe found in the equipment and methods which are usual nowadays forcomputer-assisted recording, processing and display of data concerningbusiness transactions which are based on business management oraccounting programs.

[0007] The data concerning business transactions are stored in entrybatches as they are recorded (input by an operator). These recordedbusiness transaction data have the function of a ledger. For every entryan entry data set is generally produced which, in addition to the valuesto be entered, specifies the relevant account and subsidiary accountswith the aid of the account numbers. In order to be able to carry out ananalysis of the totals produced for an account the entry data sets areusually browsed successively and the entry data sets which concern thedesired account are filtered out. This “filtering out” of the data setsconcerning a specific account from a large number of data sets slowsdown the analyses considerably. The entry values concerning the desiredaccount are then added (balanced), and a differentiation according topositive and negative values (debit and credit) can be made. Thus aftersuch a run-though (or batch run) carried out within the framework of ananalysis the account balances are obtained which are then processed forfurther business management analyses (e.g. balance sheet, profit andloss calculation). As a rule such analysis runs are carried out afterthe end of each month. A disadvantage of this is that also currentanalyses can only be obtained in each case after the conclusion of abatch run carried out possibly contemporaneously at the end of a month.In spite of a contemporaneous recording of the data concerning theindividual business transactions, a constantly current analysis of thesebusiness transactions is not possible. In the case of large quantitiesof data concerning business transactions to be processed, updating bymeans of analysis runs at the end of predetermined time intervals alsobrings with it the disadvantage that these analysis runs themselvesagain take a considerable time, so that in practice current analyses arenever available.

[0008] The object of the invention, therefore, is to create a method ofrecording and processing data concerning business transactions in acomputer system which facilitates a quicker creation of current businessmanagement analyses.

[0009] This object is achieved according to the invention by a methodwith the features of claim 1.

[0010] The method for recording (i.e. acquiring) and processing dataconcerning business transactions is carried out in a computer systemwith at least one processing unit (e.g. a CPU), at least one storageunit (for example RAM, ROM, disk storage device), input means (forexample keyboard, mouse, microphone with speech recognition means) andoutput means (e.g. display screen or printer) and with datacommunication means which connect the input and output means and theunits of the computer system to one another. The computer system maycomprise one single computer or also a plurality of computers linked toone another via a network. The data communication means encompass thebus systems as well as the network communication means.

[0011] The data concerning a business transaction specify its type andtime and values of the business transaction which are associated withthis time and indicate changes. Associated with each businesstransaction are predetermined accounts in which the values of thebusiness transaction should effect a corresponding change in accountvalues. Thus the time of a business transaction is the time at which dueto economic targets and/or legal requirements the change of value whichcharacterises the business transaction is to become effective on theassociated accounts. The changes include for example disposals of cashand/or goods. The values of the business transaction are characterisedby an amount with a preceding sign, and the preceding sign can bespecified implicitly by the type of business transaction. The values canadditionally be characterised by a unit, for example a currency or aunit of quantity, in which case in the even of erroneous informationconcerning a unit this follows implicitly from the type of businesstransaction (for example implicit assumption of the national currency).The values for the business transaction should effect a “corresponding”change of account values, i.e. the changes of account values do not needto be identical to the values of the business transaction. Accountvalues are for example stock values or yield values which relate to aneconomic enterprise in a business year.

[0012] In the method according to the invention at least one ledgerstructure is provided which has a store structure for ordered storage ofbook data sets, each book data set being associated with a businesstransaction. A ledger structure should be understood here quitegenerally to mean a structure for ordered collection of records of anytype. Each book data set is associated with precisely one businesstransaction, whereas one business transaction can also effect severalbook data sets. Each book data set (i.e. each data set of a ledgerstructure) has associated with it a record identifier whichunambiguously characterises the ledger structure and the book data setin the ledger structure, and each book data set has an accountidentifier. The record identifier is produced for example from theidentification number of the ledger structure and a serial number of thebook data set in a list or table. The record identifier is “associatedwith” the book data set, i.e. the identifier of the ledger structuredoes not have to be contained in the book data set; it can ensueimplicitly from the book. Likewise the identifier of the book data setin the ledger structure also does not need to be contained in the dataset; it can follow implicitly from the position or address of the dataset. The account identifier is the most significant content of a bookdata set (in addition to this, the book data set can contain furtherinformation, for example entry texts); the account identifier can forexample contain account numbers. The account identifier identifies atleast two selected accounts which depend upon the type of businesstransaction. One of the at least two selected accounts is a book accountwith which the ledger structure is associated. The other account or thefurther accounts of the at least two selected accounts arecross-accounts associated with the book account. A ledger structure canalso be associated with a plurality of book accounts.

[0013] In the method according to the invention, for each account anaccount object is formed, an object being understood to mean a structurewhich encompasses not only data (also denoted as status) but alsooperations which can be carried out on or with the data (also denoted asmethods). This object can be accessed by means of an exchange ofmessages via previously defined interfaces. Each account object has anidentifier data structure and a store structure for ordered storage ofpartial entry data sets (or partial data sets). A “structure” should beunderstood here to mean a logical arrangement of data or statuses of anytype. The identifier data structure identifies the appertaining accountand moreover preferably specific relations to other accounts andspecific operations, for example the form of the display presentation ofdata of this account. Each partial entry data set (or partial data set)of the store structure contains the record identifier of a book data setassociated with it as well as at least one value of a businesstransaction which should effect a corresponding change of accountvalues. The partial entry data sets together with the associated bookdata set of the ledger structure form a total entry data set. A businesstransaction can generate a plurality of total entry data sets. Thepartial entry data sets stored in the store structures for orderedstorage of the account objects fulfil a record function. In contrast tothe prior art, however, these entry data sets are no longer required forthe usual business management analyses later after the method accordingto the invention has been carried out in the recording of businesstransactions. The record identifier contained not only in the book datasets but also in the appertaining partial entry data sets facilitatesco-ordination of these components of the total entry data set andoptionally a subsequent retrieval in the search for individual entries.In addition to the at least one value of the business transaction whichshould effect a corresponding change of account values, each partialentry data set can also preferably contain further data (values,information text, etc.) concerning the account.

[0014] In the method according to the invention, in the recording ofdata concerning a business transaction the following steps are carriedout:

[0015] In a step (a) a ledger structure, an account object of a bookaccount with which the selected ledger structure is associated, and atleast one account object of a cross-account are selected as a functionof the type of business transaction, and the data concerning thebusiness transaction are read in. “Read in” means quite generally herethat the data are obtained from an input buffer (which is filled on thebasis of user input) or are transmitted from time-dependent provideddata from a program for automated business transactions (for exampleautomatic depreciation entries). Other forms of data acquisition arealso conceivable.

[0016] In a step (b) a book data set and at least two partial entry datasets are generated from the read-in data and the book data set is storedin order in the selected ledger structure. This is achieved for exampleby a program associated with the account object of the book account.

[0017] In a step (c) the at least two partial entry data sets are sentto the appertaining account objects of the book account and of thecross-account or the cross-accounts, the partial entry data setscontaining the values of the business transaction which should effectcorresponding changes of account values.

[0018] Finally in step (d) the partial entry data sets are received inthe account objects and stored in the appertaining store structures forordered storage.

[0019] The steps (a), (b), (c) and (d) do not strictly need to becarried out in the stated sequence. For example, after the selection ofa ledger structure first data can already be read in, and then a bookaccount can be selected on the basis of the first data. After selectionof a book account further data can already be read in and from these abook data set and a first partial entry data set for the account objectof the book account can be generated. This generated partial entry dataset can also already be sent to the account object of the book accountbefore a cross-account is selected. In alternative embodiments of themethod according to the invention it may prove sensible first of all toread in all the data, to generate the book data sets and partial entrysets before the first partial entry data sets are sent to the accounts.

[0020] In recent years there have been significant increases in both theprocessing power and the storage capacity of computer systems; furtherincreases in power are to be expected. The method according to theinvention uses these increases in power in an ideal way by allowing anincrease in the message traffic between account objects in order tofacilitate a contemporaneous updating and thus a high speed in thecreation and output of analyses. The account objects can for exampleremain on various computers with different hardware equipment andoperating systems which are connected to one another via a network (forexample a LAN or an intranet/internet using the TCP/IP). Furthermore,the method according to the invention is suitable for the use of anobject-oriented system, particularly for the use of an object-orientedprogramming for creation of the software structures which are necessaryfor carrying out the method. The use of the object-oriented approachalso facilitates the simple introduction of a comprehensive securityconcept for the data processing and the protection of the assets of theenterprise.

[0021] A preferred and advantageous variant of the method according tothe invention is characterised in that the account objects also eachhave at least one collective store structure. Each collective storestructure (which is present for example in the form of a list or table)comprises a plurality of data storage fields, wherein each data storagefield is associated with a time interval having a start time and an endtime within a calendar year and stores a sum value. The start and endtimes of a first number of data storage fields are chosen so that thetime intervals each correspond to a calendar month, i.e. there is a datastorage field or a plurality of data storage fields for each calendarmonth in the collective store structure. The selection of calendarmonths as primary time intervals is based on the usual requirements ofan accounting system. Naturally, further data storage fields can beassociated with further or other time intervals. Each sum value isproduced from a start value and addends. The addends are in each case apredetermined function of the values of a business transaction. Thestart value in the data storage field of a collective store structure ofan account object can for example be zero. By means of the predeterminedfunction the addend depends upon the values of one single businesstransaction, but conversely a business transaction can effect aplurality of addends. The predetermined function is preferably the samefor each data storage field of a collective store structure. In step (d)after the receipt of the partial entry data sets the collective storestructures are updated by adding up the addends formed from the valuesof the business transaction contained in the partial entry data sets inthe data storage fields corresponding to the time of the businesstransaction. The ordered storage of the partial entry sets and theupdating of the collective store structures can be carried out in anysequence.

[0022] These collective store structures increase the speed of analysisstill further. Current sum values are continuously held for the accountobject provided with the collective store structure; with regard tothese sum values the monthly batch runs can be omitted.

[0023] An advantageous variant of the method according to the inventionis characterised in that the collective store structures have a secondnumber of data storage fields in which the start and end times arechosen so that the time intervals in each case correspond to a calendarday, and that not only the time intervals of the first number of datastorage fields which each correspond to a calendar month but also thetime intervals of the second number of data storage fields which eachcorrespond to a calendar day completely cover the time interval of acalendar year once. The provision of separate data storage fields foreach calendar day has the advantage that current analyses on the basisof the account values can also be created within the months at highspeed. Furthermore, those financial years which differ from the calendaryear and end in the course of a month, as well as the conversion from afinancial year corresponding to a calendar year to a financial yearwhich differs from the calendar year, do not present any difficulties.If this is desired, this embodiment of the method according to theinvention can also be further developed so that a third number of datastorage fields is provided in which the time intervals each correspondto an hour of the calendar day. These advantageous further developmentsdo indeed require substantially greater amounts of storage, but in viewof technical developments the provision thereof is increasingly lessproblematical. Advantageously the plurality of data storage fieldscomprises at least one data storage field of which the time intervalcorresponds to the entire calendar year. Thus this data storage field(also called a year store) contains the total result of the calendaryear which can be retrieved updated at any time.

[0024] The start values of the data storage fields can preferably be seteither to equal zero, to a sum value of a data storage field of the samecollective store structure or to the sum value of a data storage fieldof another collective store structure of the account object. When thestart value of a data storage field is set to zero, then only theaddends which are a function of the values of those businesstransactions of which the times fall within the time interval of thedata storage field, i.e. in the course of the month or of the day, areadded up in the data storage field. The case where the start values ofthe data storage fields are set to the sum value of another data storagefield of the same collective store structure encompasses above all thecase where the start value of a data storage field is set to the sumvalue and thus simultaneously to the end value of a data storage fieldassociated with a preceding time interval. For example the start valueof a day store is set to the sum value of the day store of the precedingday. If the start value of the day store of the first day of a month isthen set to zero, as a result the day stores contain a sum value whichrelates to a time interval from the beginning of the month up to therespective day. If on the other hand the start value of the first day ofa month is set not to zero but to the end value of the last day of thepreceding month, then all day stores of this collective store structurecontain the sum values which relate to a time period from the beginningof a year up to the respective day.

[0025] The predetermined function according to which the addends arecalculated from the values of the business transaction preferablyencompasses the following five cases: In a first case the addend is setequal to a value of the business transaction. Thus the resulting sumvalue corresponds to a balance of the appertaining values of thebusiness transaction for the respective time interval. In a second casethe addend is set equal to a value of the business transaction so longas this is greater than zero; otherwise the addend is set equal to zero.This produces a sum value which only adds up the positive values of abusiness transaction and corresponds to a credit balance. The sameapplies to the third case, in which the addend is set equal to a valueof the business transaction so long as this is less than zero, andotherwise is set to zero. This produces a sum value which corresponds toa debit balance. In the fourth variant a value of the businesstransaction is multiplied by a constant factor in order to calculate theaddends. This is used for example in a store structure which serves forstorage of a quantity of goods in units of mass (for example inkilograms), in which however the value of a business transaction, forexample a discharge quantity, is present in a unit of volume (forexample in liters). The constant factor then corresponds to astandardised density (mass=density*volume). Finally, in a fifth case avalue of the business transaction is multiplied by a variable factorheld in a data storage field of a further collective store structurewhich corresponds in the time interval. This case can be used when thevalues in the collective store structure are stored in a foreigncurrency but the input is made in the national currency. The variablefactor then corresponds the changeable exchange rate. The exchange ratesare held in a further collective store structure, and their entry isupdated in each case at the beginning of the time interval with the aidof a message containing the exchange rate which is sent to the accountobject.

[0026] The store structure for ordered storage of the book data sets ofthe ledger structure and the store structures for ordered storage of thepartial entry data sets of the account objects are preferably sorted orindexed lists or tables which are sorted or indexed according to theserial number of the entry of the data sets or according to the time ofthe business transaction. Lists or tables could also be used which areindexed according to several criteria, for example not only according tothe serial number of the entry of the data sets but also according tothe time of the business transaction. Such lists or tables can beproduced and managed in a simple manner; the tools for manipulating themare well known in the prior art.

[0027] An advantageous variant of the method according to the inventionis characterised in that the identifier data structures of the accountobjects of the book accounts each contain an indication of thecross-accounts which can be associated with them. In method step (a) theat least one account object of a cross-account is then selected as afunction of the indication of the cross-accounts which can be associatedwith the book account. Advantageously the identifier data structures ofthe account objects of the cross-accounts each contain an indication ofthose accounts with which they can be associated as cross-accounts.Account objects which concern accounts which can be not only bookaccounts but also cross-accounts preferably contain both indications.For example, the accounts contain as indication a table for accounts andcross-accounts. The provision of such an indication increases thesecurity in recording data concerning business transactions, becausewith it the possibility of erroneous inputs and association of incorrectaccounts is reduced.

[0028] In a preferred variant of the method according to the inventionanalysis diagrams are provided which have positions with positionvalues, wherein changes of account values effect changes ofpredetermined position values. The analysis diagrams in a graphicalrepresentation can for example be in the form of a table with lines andcolumns; the positions are then the individual table fields. Forexample, account values or position values which are calculated fromaccount values can be represented in these table fields. In thepreferred variant of the method according to the invention, for at leastone selected position of an analysis diagram an analysis object isformed which has an identifier data structure and at least onecollective store structure. The makeup of the collective store structureof the analysis object corresponds to the makeup of the collective storestructure of an account object. However, in the collective storestructure of the analysis object the addends are a predeterminedfunction of those changes of account values which are effected on thebasis of business transactions of which the time falls within the timeinterval. In the recording of the data of a business transaction thefollowing further steps are then carried out. In a step (e) at least oneupdate data set determined for a selected position of an analysisdiagram is generated from the values of the business transactioncontained in a partial entry set. The update data set is generated in atleast one account object of those account objects which have received apartial entry data set. The update data set is then sent to at least oneanalysis object associated with the account object. Then in a step (f)the update data set is received in the at least one associated analysisobject. Then the collective store structure of the analysis object isupdated by adding up the addends formed from the values contained in theupdate data set in the data storage fields corresponding to the time ofthe appertaining business transaction.

[0029] This use of analysis objects and update data sets according tothe preferred embodiment of the method according to the invention hasthe advantage that certain positions (for example table fields) ofanalysis diagrams (for example a profit and loss calculation) whichresult from certain account values are continuously updated. Thisfacilitates an immediate retrieval of the totals of values of differentaccounts for certain analyses. For example the account objects which areeach associated with a debtor (customer) send update data sets to ananalysis object which combines a group of debtors. This combination of agroup of account objects into one analysis object also simplifies therecording and processing of data of planned business transactions. Whenthe method according to the invention is used for the processing of dataconcerning planned business transactions it is hardly possible to carryout simulation of planned business transactions for individual customers(debtors). Instead of this, values for a group of debtors and thus agroup of debtor accounts can be simulated and recorded with the aid ofthe method according to the invention. These planned values which areheld in collective store structures of the analysis object can then becompared later in the current financial year with the continuouslyupdated actual values for a group of debtors. In the absence of theanalysis object this would require the continuous addition of theindividual accounts.

[0030] The said preferred embodiment of the method according to theinvention is preferably characterised in that for the partial entry datasets and the update data sets a standard format is used and thatmessages of a standard format are generated for sending the partialentry data sets and the update data sets to the account objects oranalysis objects. This simplifies the system of program and datastructures to be created for the implementation of the method accordingto the invention and facilitates the exploitation of the advantages ofobject-oriented programming.

[0031] In the said preferred embodiment of the method according to theinvention the identifier data structure of the account object generatingthe update data set preferably has a list of analysis object identifiersof the associated analysis objects. For example, the analysis objectidentifiers are likewise unique character strings or numbers which likeaccount numbers are assigned to the analysis objects. Each accountobject which generates update data sets then contains a list of theanalysis object identifiers.

[0032] In a variant of the preferred embodiment of the method accordingto the invention the analysis diagrams have positions of a lowest levelwith which predetermined collective store structures of predeterminedaccount objects are associated. As a function of an output commandindicating an analysis time in a financial year a graphic output of ananalysis diagram is generated via an output means. The analysis time isfor example a qualifying date. In the graphic output, the total of thesum values of those data storage fields of the collective storestructure of the account object of which the time intervals cover thetime period from the beginning of the financial year up to the analysistime (exactly once) is output at each position of the lowest level whichis associated with an account object. The total of the sum values ofthose data storage fields of the collective store structure of therespective analysis object of which the time intervals cover the timeperiod from the beginning of the financial year up to the analysis timeis output at the selected positions which are associated with analysisobjects. At the remaining positions values are output which arecalculated from the values of other positions. Thus in order tocalculate the output values of a graphic output of an analysis diagramonly a few addition operations are necessary. Thus the output of theanalysis diagram can take place in the shortest time. Preferably thosepositions of the analysis diagram which add up a large number of accountvalues are provided as selected positions with analysis objects.

[0033] Input buffer stores in which the incoming values of the partialentry data sets or update data sets are buffered until the respectivecollective store structure can be updated with the values are preferablyassociated with the collective store structures of the account objectsand analysis objects. These input buffer stores are always advantageouswhen the updating of a collective store structure must be deferredbecause of a priority of other processing operations. When during thegeneration of a graphic output the input buffer store of an accountobject or an analysis object still contains values with which a timebefore the analysis time is associated, then the graphic outputgenerated from the collective store structure cannot contain any exactvalues. In this case a notice to the user is generated which informs himthat there are still unprocessed values in the processing pipeline.

[0034] Preferably all account objects have at least a first collectivestore structure of which the sum values correspond to an amount whichrelates to a first unit, preferably to a national currency. As a ruleall account objects and analysis objects have such a first collectivestore structure for the values in the national currency. Furthermore,certain account objects can have further collective store structures ofwhich the sum values each correspond to an amount which relates to asecond unit. The second unit can for example be a foreign currency or anumber of items, a mass or a volume of certain goods. With the aid ofsuch account objects it is possible to generate quickly not onlyanalyses in the national currency but also certain analyses which relatefor example to a foreign currency or to stocks of goods (for example forthe planning of orders).

[0035] In preferred variants of the method according to the inventionthe account objects and analysis objects contain not only actualcollective store structures for the current calendar year which storevalues resulting from business transactions actually concluded, but alsocollective store structures for one or more elapsed calendar years. Thispermits the simple and quick generation of output of analysis diagramswhich contain comparisons with elapsed financial years. In a preferredembodiment parallel actual collective store structures for the currentcalendar year three elapsed financial years are provided. The data forearlier years are held in an archive. In a preferred variant of themethod according to the invention account objects and analysis objectsselected for planning each have at least one plan level collective storestructure for the current calendar year and one or more future calendaryears which store values resulting from planned business transactions.Planned business transactions simulate future actual businesstransactions. In the method according to the invention the data forplanned business transactions are recorded and processed with the aid ofplan level collective store structures of the account objects andanalysis objects in the same way as the data for actual businesstransactions with the aid of actual collective store structures. Thusfor the planning of business transactions a system is used which isidentical to the actual accounting. This facilitates a simple comparisonof the plan data with the actual values. Plan level collective storestructures are set up for example for the current calendar year and fivefuture calendar years. In addition an overflow store structure can beset up for plan data which relate to business transactions lying furtherin the future (for example long-term credits or depreciations). Otherprocess level collective store structures can be set up between thelevel of the plan collective store structure and the level of the actualcollective store structure. For example the account objects and analysisobjects can each have at least one process level collective storestructure for the current calendar year and one or more future calendaryears which store values which result from values for uncompletedbusiness transactions resulting from purchase, storage, productionand/or sales agreements to be implemented in the respective calendaryear. In a preferred embodiment of the method according to the inventionup to four levels of collective store structures can occur in a calendaryear: a plan level, a process level (for purchasing, storage, productionand sales), a liquidity calculation level and an actual level.

[0036] Due to the passing of time, and particularly due to the turn ofthe year, plan years become the current year or the current year becomesa previous year. In each case a new plan year ensues, for whichinitially only the plan level and/or further levels are set up and thusheld ready. In the further course of time the process level isimmediately booked. When a plan year becomes the current year the actuallevel is processed. The plan level can also be retained for elapsedyears if for example analyses regarding the quality of the planning arerequired.

[0037] Further advantageous variants of the method according to theinvention are characterised in the subordinate claims.

[0038] The invention is described in greater detail below with referenceto a preferred embodiment. In this explanation reference is made todrawings in which:

[0039]FIG. 1 shows a diagrammatic sketch which illustrates an accountobject, a ledger structure and the messages transmitted in the recordingof data concerning business transactions;

[0040]FIG. 2 shows a section of a display screen representation of anaccount; and

[0041]FIG. 3 shows a diagrammatic sketch which illustrates an analysisobject and the transmission of an update data set from an account objectto the analysis object.

[0042] In the following detailed description essential components of anintegrated planning, bookkeeping, monitoring and reporting system aredescribed in which the method according to the invention is implemented.The system is capable of displaying on a screen (or printing out) allanalyses which are necessary for management of the business after theyare called up with current values, the data being constantly updated.Essential components of the integrated planning, bookkeeping, monitoringand reporting system are a plurality of account objects which are basedon a universal basic account object. The system further comprisesstandard analysis schemes for generation and output of businessmanagement analyses, these standard schemes accessing not only theaccount objects but also additional analysis objects, wherein theanalysis objects contain data which result from the data of the accountobjects and are constantly kept up to date by transmission of data setsfrom the account objects to the analysis objects. Not only the accountobjects but also the analysis objects use a universal collective storestructure for holding the constantly updated data. The account objects,analysis schemes and the store structures as well as their use inmethods for recording, processing and output of data concerning businesstransactions are explained in greater detail below.

[0043] In the introduction it has already been explained what is to beunderstood by a business transaction. In the following description abusiness transaction may for example be assumed which is based upon aninvoice being sent to a customer. The time of the business transactionis for example the time of issue of the invoice or the invoice date. Thevalues of the business transaction are the sums of money contained inthe invoice as well as the delivery quantities stated on the invoice.Issue of the invoice constitutes the type of business transaction. Inorder to record such an issue of an invoice in a bookkeeping system itis usual for example for the invoice amount (turnover tax is ignoredhere) to be booked to a debtor account for the invoice addressee(customer) and for the proceeds to be booked to the cross-account. Thusthe recording of the data concerning the business transaction usuallycomprise storage of the data in association with at least two accounts.In this case the sums of money booked to the accounts must cancel eachother out or be equal in a predetermined currency.

[0044] If subsequently further invoices are issued for example for thesame customer or for other customers, then this results in severalsimilar business transactions which lead to similar entries on the sameaccounts (realisation account or debtor account of a customer) or onseveral similar accounts (debtor accounts of several customers). If forexample an analysis required concerning the invoicing businesstransactions, then certain values of the entry sets recorded on theaccounts are to be added up over predetermined time intervals (monthsand days of a financial year for example) and the totals are to beoutput in a suitable form (analysis scheme).

[0045] In the system described here, first of all account objects areprovided which comprise not only all data concerning an account but alsoall operations which can be carried out on these data. An account objectconstitutes a closed entity which can only be accessed via a definedinterface. In order to access the account object, messages aretransmitted to the account object or are received from the accountobject via this interface. The messages transmitted to the accountobject comprise partial entry data sets, i.e. those parts of a data setbased on a business transaction which concern the respective account.

[0046] Account objects are formed for all accounts required in theaccounting system. For example debtor account objects for each customerof a business, creditor account objects for each supplier of thebusiness, bank account objects for each bank account, materials accountobjects for each type of material, property accounts for each type ofgoods, property accounts for property such as buildings, land andmovable economic goods, and many further account objects are provided.

[0047] As shown in FIG. 1, the data of the accounts objects first of allcomprise an identifier data structure. The identifier data structurecontains data identifying the account (for example an account number, anaddress or a characteristic character string) and data whichcharacterise certain properties of the account. The data of the accountobject further comprise a store table for partial entry data sets, i.e.parts of entry data sets which concern the account. The partial entrydata sets are stored in order, preferably in chronological order, inthis store table. In addition to an unambiguous identification thepartial entry data sets contain values of the business transactionswhich are to be booked to the appertaining account. The identificationdata will be described later with reference to the ledger structure usedfor entering. The values comprise not only the currency amounts whichare crucial for financial accounting but also, depending upon the typeof account, foreign currency amounts, details of quantities andadditional information of the partial entry data set.

[0048] The account objects further contain a plurality of collectivestore structures. A collective store structure comprises a plurality ofdata storage fields which are each associated with time intervals andwhich store a sum value formed from a start value and an addend, wherethe addends are in each case a predetermined function of the values of abusiness transaction. The time intervals are preferably calendar days,calendar months and the calendar year associated with the collectivestore structure. Thus for each of the 365 days (366 days) of a calendaryear, each of the 12 calendar months and for the year a respective datastorage field is provided. In the simplest case the function with whichthe addend is produced from a value of a business transaction is anequation, so that the value of the business transaction is added updirectly in one of the day, month or year stores. In the simplest casethe totals of the values of those business transactions of which thetime falls within the respective time interval are stored in the datastorage fields of the collective store. In this case the start value cabe set to zero or to the end value of a data storage field of apreceding time interval. In the first-mentioned case each day store forexample stores the total from the business transactions of therespective day; in the second case each day store stores the total ofall business transactions from the beginning of the year or of the monthup to the respective day (including the business transactions occurringon the day). In a simple summing collective store incomings are addedand outgoings are subtracted. If the closing stock of a previous year ischosen as the start value for the first day store (for the 01.01.), thefirst month store (January store) or the year store, then the respectivestore indicates the current stock. Such a configuration may be chosenfor example in the case of account objects of stock accounts.Alternatively it is possible to keep the end value of the previous yearin a separate store and then to add it to the respective value of thecurrent year when an analysis is required. In the case of accountobjects of yield accounts the start value of a collective storestructure is set to zero. Preferably in the case of each account objectsuch a simple collective store structure is provided which simplybalances up the values of the business transactions concerning therespective account which are relevant for the financial accounting. Sucha collective store structure which contains the balance of therespective account (yield account or stock account) allows for example asimple analysis for a profile and loss calculation or a balance sheetfor a freely chosen qualifying date within the current calendar year.The operations (methods) used for the analysis then only need to accessthe respective day and month stores and do not need to add up all thepartial entry data sets for the relevant time period.

[0049] Furthermore in the case of certain account objects furthercollective stores are provided in which the addends are anotherpredetermined function of the values of the business transactions. Forexample separate collective store structures for debit and credit valuesof the business transactions are provided. Then the value of the addendwhich is added up in the data storage field of a collective storestructure depends upon the sign preceding the value of a businesstransaction. Moreover, collective store structures can be provided forquantity values. For example, a collective store structure which storesa stock quantity of a fluid, for example heating oil, in units ofvolume, for example in liters, can be provided. Then when the values ofa business transaction, for example the quantity of heating oil, arestated in a unit of weight, for example in kilograms, then for theaddition in the collective store structure the weight given in thebusiness transaction for an incoming or outgoing of heating oil wouldhave to be converted into a volume. This takes place by multiplicationby a factor which depends upon the density of the heating oil. Thismeans that the addend for the collective store would be a product of avalue of a business transaction and a fixed predetermined factor. Thefactor can for example be stored in the identifier data structure of theaccount object. Finally, a case is also conceivable in which the valueof a business transaction is multiplied by a variable factor. This maybe the case for example when the value of a business transaction is acurrency amount in the national currency and the additional collectivestore structure stores the corresponding currency amount in a foreigncurrency with variable exchange rate (for example a group currency). Thevariable exchange rate can beheld in a further collective storestructure of the account object.

[0050] Finally the account objects can contain a further store structurewhich is denoted in FIG. 1 as a buffer. The buffer store structureserves for example to record the received partial entry data sets beforethey are stored in (chronological) order in the store table or beforetheir values are added up on the collective store structure. Furthermorethe buffer store structure can serve to record store contents preparedfor a display. The operations by which the data are stored in the bufferstore structure and removed from the buffer store structure and insertedinto the store table or by which the values in the collective storestructure are added up are likewise components of the account object.

[0051] The chronologically ordered store table for partial entry datasets and the collective store structures are first of all provided forthe current calendar year. Furthermore, however, the account objects canalso contain store tables and collective store structures for pastcalendar years. Also collective store structures for future or planyears are also preferably set up, for example for five years ahead.Finally several levels of collective store structures are provided notonly for the current year but also for some future years: a level forthe actual values of the actually accomplished business transactions, aliquidity level, a level for uncompleted business processes (i.e. forfuture business transactions for which an agreement already exists) anda level for planned values. Further levels, for example for global plansand detailed plans, are conceivable. The collective store structures forthe plan level are first of all set up for as many plan years ahead ascorrespond to a plan period. With the expiry of a calendar year in eachcase a new plan year is opened up and the corresponding collective storestructure set up. The input or recording of planned values correspondsto the input of data concerning business transactions at the plan level.If at a later stage concrete agreements concerning future deliveries ororders for goods are concluded, then these data are recorded as businesstransaction data in the second level, the process level or level forunfulfilled business processes. In the third level, the liquidity level,for example deliveries of goods are recorded for which not invoice hasbeen issued as yet. Finally in the fourth level, the actual level, whichconstitutes the actual bookkeeping level, the invoicing or receipt ofmoney is then for example recorded.

[0052] Thus the integrated planning and accounting system has theadvantage that a unitary structure is used for the planning and theaccounting. This for example simplifies checking of the quality of theplanning with reference to the actual business transactions.

[0053] A ledger structure is also shown in FIG. 1. The ledger structurehas an identifier, for example a book abbreviation in the form of anumber or a character string. The ledger structure further contains astore table for book data sets. The ledger structure is an essentialelement in the orderly recording of entry sets which are preferablyrecorded chronologically and fulfils the essential aspects of the recordfunction. The term “ledger structure” points to a function similar tothe conventional ledger. The ledger and also the ledger structure servefor recording the entry operations in chronological sequence. The ledgercontained not only a serial number (entry number) but also the accountsconcerned by the entry (account numbers) and other pieces of informationsuch as for example an entry text. In order to combine the values of anaccount which are to be entered, all entry data sets of the ledger whichconcern this account would have to be combined (added up). In contrastto the known ledger, the ledger structure of the system according to theinvention merely records the account numbers concerned by an entry dataset and an identifier. The identifier and the account numbers togetherform the essential content of the data sets, which are called book datasets here, stored in an ordered store table of the ledger structure. Thevalues of the entry which concern the respective accounts as well asfurther information are no longer stored in the ledger structure but aspartial entry data sets in the respective account objects.

[0054] In the simplest case the accounting system according to theinvention can contain a ledger structure for all accounting operations.However, the accounting system preferably contains a plurality of ledgerstructures which are associated with certain subject areas. For examplea ledger structure with the name “sales book” can be provided for alldebtor entries, in which case the ledger structure is associated withthe debtor accounts. A further ledger structure with the name “DeutscheBank, national currency, current account” can for example record onlythe incomings and outgoings associated with a bank account and can beassociated with this bank account.

[0055] When the data of a business transaction are recorded, a ledgerstructure is selected. This takes place for example by means of acorresponding user input. Then for example the user notifies that theinput of a business transaction into this ledger structure (for exampleinto the sales book) is intended. As a result a book data set isgenerated with which is associated an identifier in the ledgerstructure, for example a serial number. Before or during the recordingof data of the business transaction or as a function of the recordeddata an account object of this book account is selected, a book accountbeing an account with which the selected ledger structure is associated.In the case of a sales book this is for example a debtor account of thecustomer. The account number of the book account, for example of thedebtor account, is likewise recorded in the book data set. Alternativelya book account (e.g. debtor account) can first of all be selected anddepending upon that the ledger structure can be selected. Before orafter the input of further data or also automatically as a function ofthe selected book account, at least one account object of across-account is selected. Finally all remaining data of the businesstransaction are read in. Using the selected ledger structure, theselected accounts and the read-in data a plausibility check of the inputcan then be undertaken. In order to carry out the plausibility check theidentifier data structures of the selected account objects arepreferably accessed, whereby the data contained therefor example containinformation concerning the respective cross-accounts which can beassociated therewith and the permissible entry types. A book data set isthen generated from the read-in data for storage in the ledgerstructure. Furthermore at least two partial entry data sets aregenerated from the read-in data. Not only the book data set but also theappertaining partial entry data sets acquire an identifier whichfacilitates association and subsequent retrieval of the book data setsand partial entry data sets which belong to one another. The identity ofthe ledger structure together with the identifier of the book data settogether form a record identification. The record, which is alwaysnecessary, is formed from the thus identified book data set and thepartial entry data sets and can be displayed or printed out. The atleast two partial entry data sets are then sent to the account objectsof the book account and of the cross-account or the cross-accounts, thepartial entry data sets containing those values of the businesstransaction which should effect corresponding changes of account values.The transmission of the partial entry data sets to the accounts takesplace by transmission of messages to the interfaces of the accountobjects, as indicated in FIG. 1. The partial entry data sets arereceived by the account objects, the data of the partial entry data setsbeing initially preferably stored in a buffer store. The successful andcomplete reception of the partial entry data sets can then be notifiedto the user by a confirmation message to the ledger structure and or acorresponding display structure. The further processing of the data ofthe partial entry data sets is then carried out within the accountobjects automatically and independently of the other account objectsconcerned. With the aid of the operations of the account objects notonly the chronological store table for the partial entry data sets butalso the collective store structures are updated.

[0056] As already described, the operations which can be carried out onthe data within an account object are a component of the account object.These operations include those which can be carried out in the case ofeach account object, for example those which concern the reading in,output and storage of data in the chronological store table and thecollective store structures. Furthermore, there are operations which areimplemented only in the case of selected account objects. In the case ofdebtor accounts such operations can for example encompass the triggeringof warnings. The operations also encompass the display of the datacontents and a selection display for the operations to a user. Theaccess to certain operations can be restricted for selected categoriesof users. The operations, which may be called modes of operation, whichcan be selected in the case of an account object are for exampledisplayed in the form of a selection list in a window which can becalled up by a user. These operations comprise for example the displayof a section of the store table for a predetermined time interval or thedisplay of certain stocks by access to the corresponding data of thecollective store structures. The operations and the data of theidentifier data structure can moreover fix the display screen input masktailored to the respective account. This input mask has input fieldswhich comprise standard fields which are present in every type ofaccount and variable fields which depend upon the type of account. Thestandard fields include for example fields for the financial year, theaccount number (or another identifier), the entry data, the recordingdate, the record number (which consists for example of a bookabbreviation of the ledger structure and a serial number) and the typeof entry. An example of a section of a screen representation for displayof entry data sets is shown in FIG. 2. The standard fields also includeat least one field into which the amounts (values) to be entered can beinput. In this case at least one field is provided for values in thenational currency. The values characterise an amount, a preceding signand a unit of measurement which may be implicitly present or explicitlystated. The preceding sign may also result implicitly from the selectedinput/display field, for example when not only a field for credit butalso a field for debit are to be provided. At least a value in thenational currency is to be recorded in a partial entry data set for anaccount.

[0057] In addition to this, further fields can be provided for amountsin foreign currencies with fixed or variable exchange rates or fordetails of quantities. The details of quantities can be differentiatedaccording to stock quantities for which the record is to be kept andinput quantities which trigger changes in the stocks. The quantities arealso differentiated with regard to the physical values used, for examplevolume, mass, weight, number of items. The physical values used can bedifferent for the stock quantities stored in the collective storestructure and the input quantities, in which case conversions are to becarried out if need be.

[0058] The variable fields used depend upon the type of account. Theseinclude for example fields for supplementary data, such as numbers ofthe bank statement and numbers of the till statement, for extraneousrecord data, such as the record date and the record number, for data onsetting value, on the period and on the tax period as well as for theaccount content, reference data, batch numbers and release data.

[0059]FIG. 2 shows a greatly simplified example of a display screenrepresentation of a sample account. Data specifying the account and thefinancial year and also the possible cross-account are set out by meansof a table. In the table the column headings give designations of thefields displayed below them. Below these are table lines, and in eachline in an upper display area these table lines display data forbusiness transactions already booked to the account. The partial entrydata sets displayed in the display area correspond for example to thelast ones recorded. Below the display area, for example below the lastrecorded partial entry data set, an input area is provided into which auser can input the values of a business transaction to be newlyrecorded. Some of the values can already be predetermined automatically.Although the input area and the display area are represented immediatelybelow one another on the screen, it is for example not necessary for thebuffer store for the input area to be located within the particularaccount object from which the data for the display area have beenacquired. Possible methods for generating the display in connection withthe recording of operator inputs and their immediate representation onthe screen and for acquiring and transmitting the recorded data areknown in the prior art and do not need to be described in greater detailat this point.

[0060] The input area for the recording of data can also be representedin the format of an input record, for example in the form of an invoice.Thus selected accounts can have associated with them different types ofinput records or input masks which are adapted to the type of accountand the types of entry taking place. Furthermore, for example, a windowcan be displayed which presents balances from extraneous records, inparticular from bank statements, so that a user whilst making theentries can follow whether his inputs produce a balance which tallieswith that of an extraneous record. Finally, it is possible to generatedisplays which represent the data of stocks. This are generated from thecollective store structures of the addressed account objects.

[0061] The stocks can be displayed for example in the form of a stockregister which can be used with open entries of invoices for incomingsor outgoings as well as with stores. This is a permanent record of theindividual part-quantities until they are exhausted. The data whichresult in the respective stocks are not deleted but are retained so thaton any qualifying date the stock and its composition can be displayed.In order to display a stock register, preferably those collective storestructures are accessed in which the start values of the data storagefields correspond to the end values of the data storage fields of therespectively preceding time interval. The end stock of the respectivepreceding year is taken as the starting stock of the current year.

[0062] In other types of account a stock table can be displayed. This isused for example when displaying certain commitments, such aswages/salaries, and taxes, such as for example turnover tax. The displaycomprises a table, on the lines of which are shown the sub-types, suchas for example obligatory and voluntary wages or obligatory or voluntaryturnover, and in the columns a total balance and its distribution overperiods of time, as a rule on a monthly basis, is shown.

[0063] A third possibility for a display which is obtained from the dataof an account object is the development table which is used inparticular in the case of items of the fixed assets. This table containson the lines sub-types, for example land, building, machines, and in thecolumns it contains the development according to entry type, beginningfrom the starting stock through incomings and outgoings to the endstock.

[0064] All account objects are based on a uniform basic structure, i.e.on an object from which the account objects have inherited predeterminedproperties. The use of account objects which are uniform in this respectfor all subject areas. i.e. for the main ledger bookkeeping withintegrated subsidiary books for customers and suppliers and fornon-integrated subsidiary books such as wages and salaries accounts,equipment accounts and materials accounts, simplifies not only theprogramming but also the operation and permits the integration of allpart-areas of accounting. Nevertheless the account objects are veryflexible and can be adapted to a large number of special requirementsfor certain types of accounts. Thus with regard to the properties of theaccount objects an account hierarchy of the inheritance is built up.

[0065] However, the system according to the invention goes a stepfurther in that not only for business management analyses, such as forexample profit and loss calculations and balance sheets at the level ofan individual business or at group level, the account objects whichcontain in their collective store structures certain summary values areaccessed and the analyses are generated therefrom, but also that specialanalysis objects are provided for all or some of the output data orpositions of the analysis scheme. The analysis objects are similar tothe account objects; in addition to an identifier data structure andcertain operations they contain one or more collective store structures.In the collective store structures those values from which the outputpresentation of a business management analysis is generated areconstantly updated. This speeds up the generation of current analysessubstantially. This is explained in greater detail below.

[0066] The analysis schemes to be generated for the output presentationare as a rule tables with a commercially usual content and thus in whichthe division into lines and columns is basically fixed. Examples of suchanalysis schemes included balance sheets and profit and losscalculations for individual businesses and groups, profit and losscalculations as cover contribution calculations, statistics, such as forexample customer group turnover statistics and article group turnoverstatistics, lists and plans for liquidity control or also analysisschemes which relate not only to specific accounts, such as for examplethe presentation of the fixed assets as a development table, whichaccess a plurality of accounts associated with the individual goods.

[0067] The analysis schemes contain a plurality of (table) fields intowhich predetermined values are to be entered before output/printing. Atthe lowest level these fields contain for example values which can beread out directly from individual account objects. Furthermore theanalyses contain a series of fields or positions of which the valuesresult from account values from several or even many account objects.Above all for the last-mentioned fields analysis objects are providedwhich contain collective store structures of the type also used in theaccount objects. The collective store structures of the analysis objectsstore summary values for predetermined time intervals from which theoutput fields of the analysis schemes can be generated in a simplemanner (few additions) without recourse to the account objects.

[0068] The constant updating of the collective store structures of theanalysis objects is—in contrast to the collective store structures ofthe account objects—carried out not on the basis of partial entry sets(which are based on the recording of data concerning businesstransactions) received by the analysis object but on the basis of updatedata sets. The update data sets are transmitted as components ofmessages from account objects to the analysis objects. Each analysisobject contains update data sets of those account objects which itbrings together in the analysis scheme or of which the account changeshave an influence on the value to be represented in the analysis scheme.

[0069]FIG. 3 shows the analysis object used in the system according tothe invention and the reception of an update data set from anappertaining account object.

[0070] The analysis object according to FIG. 3 in turn comprises data aswell as operations (methods) which can be carried out on the data Thedata include an identifier data structure which unambiguouslycharacterises the analysis object. The identifier data structurecontains for example a number which characterises the analysis scheme inwhich is situated the position or the table field with which theanalysis object is associated. Furthermore the identifier data structurecontains an unambiguous identification of the position within theanalysis scheme (e.g. column and line number). An analysis object canalso be associated with a plurality of analysis schemes and differentpositions within the plurality of analysis schemes. For example ananalysis object can combine a group of debtor accounts. Such an analysisobject combining debtor accounts can be used in various analysisschemes. The identifier data structure can also contain anidentification of those account objects from which the analysis objectmay receive update data sets. This facilitates checking with regard tothe receipt of permitted update data sets.

[0071] The data of the analysis object also include at least onecollective store structure. Each collective store structure contains—asalso do those of the account objects—a plurality of data fields whichare associated with time intervals of the calendar days, calendar monthsand of the calendar year. In the data storage fields values are added upwhich by means of predetermined functions are calculated form the valuesof the update data sets. In the simplest case an update data setcontains a value of a business transaction to be added in an accountobject and which is to be added in the a similar manner in thecollective store of the analysis object. In this simple case theanalysis object carries out the same updates on the collective store asthe account objects associated with it, albeit for the total of theaccount objects. Like the account objects, the analysis object cancontain collective store structures for further values (foreigncurrencies, quantities), collective store structures for actual valuesof preceding years as well as collective store structures for severallevels (plan level, process level, liquidity level).

[0072] The analysis object can also contain a buffer in which the dataof the received update data sets is first of all entered before theanalysis object undertakes an update of its collective stores with theaid of the methods inherent in it.

[0073] The analysis object receives the update data sets from accountobjects associated with it. The account objects, which transmit updatedata sets to certain analysis objects, contain a data structure whichidentifies those analysis objects to which update data sets should besent. This identification structure, also denoted as a read-in strip,for the receiver of update data sets can additionally contain conditionswhich analysis objects are to be supplied with update data sets in thecase of which business transactions. When an account object receives apartial entry data set which is based on a predetermined businesstransaction with a time associated with it, then operations are startedin the account object which as a function of the read-in strip establishwhether update data sets are to be generated and sent to predeterminedanalysis objects. Then the values to be introduced into the update datasets are taken from the partial entry data set and stored in the updatedata sets. As a rule only some of the data of the partial entry data setare taken for an update data set. For example, only the values relatingto the currency are taken from a partial entry data set which containsnot only amounts of currencies but also details of quantities of goodsfor an analysis object which only comprises a financial analysis.Conversely, for an analysis object which relates to quantities of goods,only those values which relate to the relevant quantities are taken froma partial entry set and put into an update data set. The update data setis sent in a message from the interface of the account object to aninterface of the analysis object. The methods implemented in theanalysis object then ensure interim storage of the update data set in abuffer and updating of the collective store structures of the analysisobject.

[0074] Furthermore it is possible that the analysis objects themselvesin turn generate update data sets from the received update data sets andsend the newly generated update data sets to superior analysis objects.For example the account objects of a business could send update datasets to analysis objects of the business which are required for ananalysis scheme of a balance sheet of the business. Then the analysisobjects of the balance sheet can in turn generate update data sets whichare transmitted to analysis objects of a superior group parent company.

[0075] Analysis objects can also comprise warning functions or can evenbe instruction or warning analysis objects (i.e. merely fulfil thesewarning functions). Such warning functions or warning analysis objectsacquire from predetermined account and/or analysis objects (to bemonitored) update data sets which contain values to be monitored. Assoon as these values to be monitored and/or certain summary functions ofthese values exceed or fall below predetermined limiting or thresholdvalues, an instruction to a user (for example to a user in a superiordepartment and/or a management level) is generated automatically by thewarning function of the analysis object or by the methods of the warninganalysis object. Alternatively it is possible in certain account objectsto implement methods which under predetermined conditions generatewarning update data sets and send these warning update data sets tosignalling analysis objects of a superior level. The two cases referredto differ in the respective place at which the conditions are monitored;in the first-mentioned case the threshold value conditions areimplemented by methods of the receiving warning analysis objects, in thelast-mentioned case they are implemented in the transmitting accountobjects.

[0076] In the case of certain analysis objects it is possible on certainlevels, in particular on the planning level, to generate update datasets directly (bypassing the account objects) from inputs of planningdata and to send these to the analysis objects so that with the aid ofthese planning update data sets the collective store structures of theanalysis object are updated for the planning level. The update data setsacquired from inputs are consequently not generated by account objects.Such a procedure is advantageous for example when an analysis objectcombines a plurality of account objects, for example when the analysisobject represents the total of all debtor accounts, and when an input ofplan data into the individual account objects (for example the debtoraccounts associated with the individual customers) is to be avoidedbecause of missing or unnecessary detailed information. In this case theaccount objects in the planning level remain unchanged or empty and anupdate data set which updates the collective store structure of theanalysis object in the planning level is transmitted directly from aplanning input to the superior combining analysis object. Since in sucha case the collective store structure of the planning level no longerrepresents the total of the individual plan collective store structuresof the account objects which remain empty, a display is also necessaryin the analysis object which indicates that the planning value of theanalysis object no longer represents the total of the planning values ofthe appertaining account objects. Such a display can be generatedautomatically when an update data set comes in not from an accountobject but directly from a planning input. In the case of analysisobjects which permit a direct input of simulated update data sets intothe planning level, on the other hand, it must be ensured that suchdirect inputs cannot occur in the actual level of business transactionswhich are actually entered. The necessary stops can be implementedwithin the framework of the methods associated with the account object.

1. Method of recording and processing data concerning businesstransactions in a computer system with at least one processing unit, atleast one storage unit, input means and output means and with datacommunication means which connect the input and output means and theunits of the computer system to one another, wherein the data concerninga business transaction specify its type and time and values of thebusiness transaction which are associated with this time and indicatechanges, and associated with each business transaction are predeterminedaccounts in which the values of the business transaction should effect acorresponding change in account values, wherein at least one ledgerstructure is provided which has a store structure for ordered storage ofbook data sets, each book data set being associated with a businesstransaction, wherein each book data set has associated with it a recordidentifier which unambiguously characterises the ledger structure andthe book data set in the ledger structure, and each book data set has anaccount identifier, wherein the account identifier identifies at leasttwo selected accounts which depend upon the type of businesstransaction, one of the at least two selected accounts being a bookaccount with which the ledger structure is associated, and the furtherof the at least two selected accounts being cross-accounts associatedwith the book account, wherein for each account an account object isformed, each account object having an identifier data structure and astore structure for ordered storage of partial entry data sets, and eachpartial entry data set of the store structure contains the recordidentifier of a book data set associated with it as well as at least onevalue of a business transaction which should effect a correspondingchange of account values, wherein in the recording of data concerning abusiness transaction the following steps are carried out: (a) selectionof a ledger structure, an account object of a book account with whichthe selected ledger structure is associated, and at least one accountobject of a cross-account as a function of the type of businesstransaction and reading in of the data concerning the businesstransaction; (b) generation of a book data set and at least two partialentry data sets from the read-in data and ordered storage of the bookdata set is stored in order in the selected ledger structure; (c)sending of the at least two partial entry data sets to the appertainingaccount objects of the book account and of the cross-account or thecross-accounts, the partial entry data sets containing the values of thebusiness transaction which should effect corresponding changes ofaccount values; and (d) receipt of the partial entry data sets arereceived in the account objects and ordered storage of the partial entrydata sets in the appertaining store structures.
 2. Method of recordingand processing data concerning business transactions as claimed in claim1, characterised in that the account objects each have at least onecollective store structure, wherein each collective store structurecomprises a plurality of data storage fields, each data storage fieldbeing associated with a time interval having a start time and an endtime within a calendar year and storing a sum value, wherein the startand end times of a first number of data storage fields are chosen sothat the time intervals each correspond to a calendar month, whereineach sum value is produced from a start value and addends, the addendsbeing in each case a predetermined function of the values of a businesstransaction of which the time falls within the time interval and withwhich the account of the account object is associated, and that in step(d) the collective store structures are updated by adding up the addendsformed from the values of the business transaction contained in thepartial entry data sets in the data storage fields corresponding to thetime of the business transaction.
 3. Method of recording and processingdata concerning business transactions as claimed in claim 2,characterised in that the collective store structures have a secondnumber of data storage fields in which the start and end times arechosen so that the time intervals in each case correspond to a calendarday, and that not only the time intervals of the first number of datastorage fields which each correspond to a calendar month but also thetime intervals of the second number of data storage fields which eachcorrespond to a calendar day completely cover the time interval of acalendar year once.
 4. Method of recording and processing dataconcerning business transactions as claimed in claim 3, characterised inthat the plurality of data storage fields comprises at least one datastorage field of which the time interval corresponds to the entirecalendar year.
 5. Method of recording and processing data concerningbusiness transactions as claimed in one of claims 2 to 4, characterisedin that the start values of the data storage fields can preferably beset (i) to equal zero, (ii) to a sum value of a data storage field ofthe same collective store structure or (iii) to the sum value of a datastorage field of another collective store structure of the accountobject.
 6. Method of recording and processing data concerning businesstransactions as claimed in one of claims 2 to 5, characterised in thatthe predetermined function according to which the addends are calculatedfrom the values of the business transaction comprises (i) setting of theaddend to equal to a value of the business transaction so that the sumvalue corresponds to a balance, (ii) setting of the addend to equal to avalue of the business transaction so long as this is greater than zero;otherwise the addend is set equal to zero so that the sum valuecorresponds to a credit balance, (iii) setting of the addend to equal toa value of the business transaction so long as this is less than zero,and otherwise is set to zero so that the sum value corresponds to adebit balance, (iv) multiplication of a value of the businesstransaction by a constant factor, or (v) multiplication of a value ofthe business transaction by a variable factor held in a data storagefield of a further collective store structure which corresponds in thetime interval.
 7. Method of recording and processing data concerningbusiness transactions as claimed in one of claims 1 to 6, characterisedin that the store structure for ordered storage of the book data sets ofthe ledger structure and the store structures for ordered storage of thepartial entry data sets of the account objects are preferably sorted orindexed lists or tables which are sorted or indexed according to theserial number of the entry of the data sets or according to the time ofthe business transaction.
 8. Method of recording and processing dataconcerning business transactions as claimed in one of claims 1 to 7,characterised in that the identifier data structure has a characterstring and/or number which unambiguously denotes the account object. 9.Method of recording and processing data concerning business transactionsas claimed in one of claims 1 to 8, characterised in that the identifierdata structures of the account objects of the book accounts each containan indication of the cross-accounts which can be associated with them,wherein in step (a) the at least one account object of a cross-accountis selected as a function of the indication of the cross-accounts whichcan be associated with the book account.
 10. Method of recording andprocessing data concerning business transactions as claimed in claim 9,characterised in that the identifier data structures of the accountobjects of the cross-accounts each contain an indication of thoseaccounts with which they can be associated as cross-accounts, wherein instep (a) the at least one account object of a cross-account is selectedas a function of its display of those accounts with which it can beassociated as cross-account.
 11. Method of recording and processing dataconcerning business transactions as claimed in one of claims 2 to 6,characterised in that analysis diagrams are provided which havepositions with position values, wherein changes of account values effectchanges of predetermined position values, wherein for at least oneselected position of an analysis diagram an analysis object is formedwhich has an identifier data structure and at least one collective storestructure, wherein the makeup of the collective store structure of theanalysis object corresponds to the makeup of the collective storestructure of an account object, wherein in the collective storestructure of the analysis object the addends are a predeterminedfunction of those changes of account values which are effected on thebasis of business transactions of which the time falls within the timeinterval, wherein in the recording of the data of a business transactionthe following further steps are carried out: (e) generation of at leastone update data set, which is determined for a selected position of ananalysis diagram from the values of the business transaction containedin a partial entry data set, in at least one account object of thoseaccount objects which have received a partial entry data set, andsending of the update data set to at least one analysis objectassociated with the account object; and (f) reception of the update dataset in the at least one associated analysis object and updating of thecollective store structure of the analysis object by adding up theaddends formed from the values contained in the update data set in thedata storage fields corresponding to the time of the appertainingbusiness transaction.
 12. Method of recording and processing dataconcerning business transactions as claimed in claim 11, characterisedin that for the partial entry data sets and the update data sets astandard format is used and that messages of a standard format aregenerated for sending the partial entry data sets and the update datasets to the account objects or analysis objects.
 13. Method of recordingand processing data concerning business transactions as claimed in claim11 or 12, characterised in that the identifier data structure of theaccount object generating the update data set preferably has a list ofanalysis object identifiers of the associated analysis objects. 14.Method of recording and processing data concerning business transactionsas claimed in one of claims 11 to 13, characterised in that the analysisdiagrams have positions of a lowest level with which predeterminedcollective store structures of predetermined account objects areassociated, that as a function of an output command indicating ananalysis time in a financial year a graphic output of an analysisdiagram is generated via an output means, and in this graphic output thetotal of the sum values of those data storage fields of the collectivestore structure of the account object of which the time intervals coverthe time period from the beginning of the financial year up to theanalysis time is output at each position of the lowest level which isassociated with an account object, the total of the sum values of thosedata storage fields of the collective store structure of the respectiveanalysis object of which the time intervals cover the time period fromthe beginning of the financial year up to the analysis time is output atthe selected positions which are associated with analysis objects, andat the remaining positions values are output which are calculated fromthe values of other positions.
 15. Method of recording and processingdata concerning business transactions as claimed in claim 14,characterised in that input buffer stores in which the incoming valuesof the partial entry data sets or update data sets are buffered untilthe respective collective store structure can be updated with the valuesare preferably associated with the collective store structures of theaccount objects and analysis objects, and during the graphic output ofan analysis scheme an instruction is generated for the user if the inputbuffer store still contains values with which a time before the analysistime is associated.
 16. Method of recording and processing dataconcerning business transactions as claimed in claim 14 or 15,characterised in that a balance sheet, a profit and loss calculation, aturnover statistic or another business management analysis for a companyor a group is represented by the graphical output of an analysis scheme.17. Method of recording and processing data concerning businesstransactions as claimed in one of claims 11 to 16, characterised in thatall account objects have a first collective store structure of which thesum values correspond to an amount which relates to a first unit,preferably to a national currency, and that at least one account objecthas at least one second collective store structures of which the sumvalues correspond to an amount which relates to a second unit, forexample to a foreign currency, a number of items, a mass or a volume.18. Method of recording and processing data concerning businesstransactions as claimed in claim 17, characterised in that all analysisobjects have a first collective store structure of which the sum valuescorrespond to an amount which relates to a first unit, preferably to anational currency.
 19. Method of recording and processing dataconcerning business transactions as claimed in one of claims 1 to 18,characterised in that the ledger structure and/or the account object ofthe book account are selected as a function of a user input, and thatthe at least one account object of the at least one cross-account isselected as a function of the input of a part of the data concerning thebusiness transaction which contains at least the type of businesstransaction.
 20. Method of recording and processing data concerningbusiness transactions as claimed in claim 19, characterised in that theuser input comprises a selection of a graphical tree structure displayedto the user on an output means.
 21. Method of recording and processingdata concerning business transactions as claimed in claim 19 or 20,characterised in that a further cross-account is always offered to theuser for selection when it is apparent that a total of predeterminedvalues of the partial entry data sets of the already selected accountscreated on the basis of the data concerning the business transaction isnot equal to zero.
 22. Method of recording and processing dataconcerning business transactions as claimed in one of claims 1 to 21,characterised in that the data read in in step (a) are held in a bufferstore in a pre-recording mode until all appertaining account objects areselected, the book data set and the partial entry data sets have beengenerated and the partial entry data sets have been checked at least toestablish that a total of predetermined values of the partial entry datasets created on the basis of the data concerning the businesstransaction is equal to zero.
 23. Method of recording and processingdata concerning business transactions as claimed in claim 11,characterised in that all the account objects and analysis objects eachcontain at least one actual collective store structure for the currentcalendar year which store values resulting from business transactionsactually concluded.
 24. Method of recording and processing dataconcerning business transactions as claimed in claim 23, characterisedin that all the account objects and analysis objects each contain atleast one actual collective store structure for one or more elapsedcalendar years which store values resulting from business transactionsactually concluded.
 25. Method of recording and processing dataconcerning business transactions as claimed in claim 23 or 24,characterised in that account objects and analysis objects selected forplanning each have at least one plan level collective store structurefor the current calendar year and one or more future calendar yearswhich store values resulting from planned business transactions. 26.Method of recording and processing data concerning business transactionsas claimed in claim 25, characterised in that the account objects andanalysis objects can each have at least one process level collectivestore structure for the current calendar year and one or more futurecalendar years which store values which result from the values of theplan level collective store structures and/or from values foruncompleted business transactions resulting from purchase, storage,production and/or sales agreements to be implemented in the respectivecalendar year.
 27. Method of recording and processing data concerningbusiness transactions as claimed in claim 25 or 26, characterised inthat the account objects and analysis objects in each case have at leastone further collective store structure for the current calendar year anda future calendar year which store values which relate to a liquidityresulting from the planned values and the actual values.